Design It! プログラマーのためのアーキテクティング入門
https://gyazo.com/64ebd7901bb406f621f52e791d621b28
Big Design UpfrontもダメだしNo Design Upfrontもだめ。Enough Design Upfront 大切なことは、最良のアーキテクチャは、その文脈によって変わるということだ。 文脈なしにアーキテクチャは成立しない。このことを強く思い出させるエピソード を 1 つ紹介しよう。Twitter は最初 Ruby on Rails で開発されたが、2009 年ころから JVM(Java VM)ベースのアーキテクチャに移行し、レスポンスとスケーラビリティ を改善した†1 。途中で大きくアーキテクチャを変更した巨大な商用アプリケーション の例だ。これは、最初の Ruby on Rails の選択が間違っていたということではない。
1章 ソフトウェアアーキテクトになる
https://gyazo.com/4651e5775f9046e7ac7cf3f4b7593588
いつどうやって届けるかを考えるがPjMではない。
ソフトウェアがビジネスの目標を満たすことを考えるがPdMではない。
コードは書くがコード以上のことも考える。
例: 品質特性とコスト
技術的負債は現状 => 継続的に価値を届けるために必要な設計 の差を埋めるのにどれだけ労力が必要かを見積もれば計測可
三つの要素と関係を用意している
モジュール: 設計時の構造、ソフトウェアが動いてなくても存在する
クラス、パッケージ、DBのテーブル
コンポーネント & コネクター：実行時に現れる。
オブジェクト、コネクション、フィルター、スレッド、プロセス
割り当て(allocation): モジュールやC&C構造がどう対応するか、それらがどう物理的に対応しているか
サーバーセンサー、ロードバランサー、チーム、人間、コンテナ
プログラマーとして開発に取り組んでいると き、あなたは毎日何十もの設計判断を行なっている。これらの判断の中には、アーキ テクチャに対して大きな影響を与えるものもある。ソフトウェアシステムの構造に影 響を与える決定を行う人であれば、誰しもがアーキテクト代行だ。名刺の肩書きが何 であれ、良い判断を行い、アーキテクチャ上の完全性を維持するのはあなたなのだ。
感想
考えてみれば当たり前ではあるがソフトウェアアーキテクトはビジネスやユーザーを考えながら多面的に判断しなくてはならない。なぜなら今どういう技術で取り組むべきかは、ビジネスの品質特性であったり、市場の状況、ユーザーのリテラシー、チームの技術スタックなど様々なステークホルダーのことを考えなくては、導き出すことができないから。
ソフトウェアアーキテクチャを三つの要素に分類してみる話は面白い。今読んでるユースケース駆動開発実践ガイドにも、実行時に存在するものと、ソフトウェアが動いていなくても概念上分けるような物の二つがあるので。 2章 デザイン思考の基礎
5章
13 章 チームのアーキテクト力を強める ..........................................213
現代のソフトウェアシステムにおいて、開発者とアーキテクトの違いはほとんどない。これは、現代のソフトウェア開発チームが技術リーダーを必要としないという意味ではない。
品質・スピード・幸福
学習を促進するための、個々の生徒に渡される支援
アーキテクトの例
設計作業を委託するためのテンプレート
ワークシートのようなものと考えても良いだろう mactkg.icon
建設的な批評
コンポーネントのスケルトンコード
良い、悪い
教科書でよくあるパターン。
lintなどもこう書いてあり、分かりやすい
Tell / Sell / Consult / Agree / Advise / Inquire / Delegate
指示 / 説得 / 相談 / 合意 / 助言 / 尋ねる / 委譲
アクティビティの例
会話をはじめよう
アーキテクチャの擬人化(11) システムメタファー(29)
一緒に作業しよう
質問ー意見ー懸念(34) リスクストーミング(35) シナリオウォークスルー(37)
9 章 アーキテクチャデザインスタジオを開く
チームが関与できている？
アーキテクチャブリーフィング(30) サニティチェック(36)
成果物を作ってみよう
ADR(20) アーキテクチャ俳句(21) インセプションデッキ(24) 感想
チームのアーキテクト力を高めたいとは思うので（自分も含め）、そのためのアクティビティがまとまってるのはありがたい。14章をいろいろ見て使えそうなタイミングで組み込んでいけると良さそう。
14章 問題理解のアクティビティ
アクティビティ 1 たった一つを選ぶ
アクティビティ 2 共感マップ
アクティビティ 3 GQMワークショップ
アクティビティ 4 ステークホルダーインタビュー
アクティビティ 5 前提リスト
アクティビティ 6 品質特性ウェブ
アクティビティ 7 ミニ品質特性ワークショップ
アクティビティ 8 POV Madlib
アクティビティ 9 応答測定のたたき台
アクティビティ 10 ステークホルダーマップ
15章 潜在的な解決策を探るアクティビティ
アクティビティ 11 アーキテクチャの擬人化
アクティビティ 12 アーキテクチャフリップブック
アクティビティ 13 CRCカード
アクティビティ 14 概念マップ
アクティビティ 15 分割統治
アクティビティ 16 イベントストーミング
アクティビティ 17 グループポスター
アクティビティ 18 ラウンドロビン設計
アクティビティ 19 ホワイトボードジャム
16章 設計をタンジブルにするアクティビティ
アクティビティ 20 アーキテクチャデシジョンレコード
アクティビティ 21 アーキテクチャ俳句
アクティビティ 22 コンテキスト図
アクティビティ 23 まずこれを読もうリスト
アクティビティ 24 インセプションデッキ
アクティビティ 25 モジュール分解図
アクティビティ 26 選ばなかった道
アクティビティ 27 学習か判断のためのプロトタイプ
アクティビティ 28 シーケンス図
アクティビティ 29 システムメタファー
17章 設計の選択肢を評価するアクティビティ
アクティビティ 30 アーキテクチャブリーフィング
アクティビティ 31 コードレビュー
アクティビティ 32 意思決定マトリクス
アクティビティ 33 振る舞いの観察
アクティビティ 34 質問－意見－懸念
アクティビティ 35 リスクストーミング
アクティビティ 36 サニティチェック
アクティビティ 37 シナリオウォークスルー
アクティビティ 38 スケッチして比較